Configurable devices have grown in use and popularity. One example of a configurable device is a programmable device. Programmable devices have evolved to the point where it is now practical and desirable to configure one programmable device with another programmable device. For example, a micro-controller can be used to program a configurable hardware device such as a programmable logic device (PLD). Alternatively, a microprocessor, a field programmable gate array (FPGA), or a digital signal processor (DSP) chip may be used to program a field programmable analog array (FPAA), an FPGA, or a DSP chip.
In one case, configuration is accomplished by programming a first device to write configuration data to some or all of the configuration data registers within a second device. After configuring the second device, it is often desirable for the first device to be able to adjust any or all of the performance parameters of the second device. Additionally or optionally, it is desirable to change the overall circuit implemented in the second device. In both cases, the adjustment or change is carried out by either (a) modifying all or part of the configuration data, and then applying the configuration data to the registers within the second device or (b) by directly modifying all or part of the configuration data contained within the registers of the second device. However, current design tools have a difficult time carrying out this modification.
Present-day computer-aided design (CAD) tools for integrated circuits have been used to program configurable devices, but are designed to provide the ability to program a target device. However, such CAD tools have no provision for configuration of the device by or from another device. More particularly, circuit design flow typically uses internal algorithms in order to combine together the user's design, information about architecture of the device, and potentially one or more pre-defined elements. The design flow then delivers a configuration data set that is suitable for configuring the target device. This technique works relatively well when the configurable device is to be loaded in its entirety, such as when the device is being loaded from a read-only memory (ROM). However, use of this technique relegates a sophisticated controller to the task of merely loading one or more complete configurations into the configurable device (or chip) because the only portion of the original design information that is available when the controller code is compiled is the resulting raw configuration data.
FIG. 1 illustrates configurable hardware flow and controller flow for such a prior art system. More particularly, a configurable hardware device 10 having analog components is provided in a manner that can be configured by a controlling device 12, such as a central processing unit (CPU). Configurable hardware flow 14 is illustrated in relation to controller flow 16 wherein a device description 18, a function library 20, a user functional description 22, and a CAD tool 24 interact such that the CAD tool generates configuration data 26. Such configuration data is then exported to configurable device 10. By way of an example, one way of doing this involves storing data in a read only memory (ROM) and allowing a field programmable analog array (FPAA) to configure directly from the ROM. Furthermore, configuration data 26 is further delivered to controller flow 16.
With respect to controller flow 16, a user program 28, libraries 30, CPU device description 32, and a compiler 34 interact such that compiler 34 generates a CPU program 36. Compiler 34 receives configuration data 26 from configurable hardware flow 14 and/or indirectly via user program 28. CPU program 36 is delivered to controlling device 12, after which controlling device 12 uses internal algorithms to combine a user's design, information about the device architecture, and pre-defined elements. Controlling device 12 then delivers a configuration data set, or a program, to configurable device 10 that is suitable for configuring such device.
Device description 18 includes information about device topology 38, as well as information about resource availability 40. Function library 20 includes information about resource requirements 42, simulation models 44, and functional timing 46. User functional description 22 includes information about a functional description, as well as information about a “schematic” or “VHDL” (VHSIC Hardware Description Language). CAD tool 24 includes information about resource allocation 52, place & route information 54, netlist conversion information 56, and configuration generation information 58.
User program 28 can be provided in any of a number of programming languages including, but not limited to, “C” language, assembly language, and PASCAL. Libraries 30 include a floating point library 60, a peripheral library 62, and an algorithm library 64. CPU device description 32 includes information about device topology 66 and resource availability 68.
Existing CAD tools are provided with configuration data alone, and are not provided with details about device architecture and sub-circuit placement. Accordingly, any external program on a controlling device, such as controlling device 12, can do little more than blindly load the configurable hardware onto configurable device 10. In order for CPU program 36 to be rendered with the ability to make useful changes to circuitry or parameters within configurable device 10, additional information is required about where components are to be placed and the criteria for setting values for such components. However, presently known techniques are incapable of providing such information.
For example, conventional practice with some field programmable gate array (FPGA) designs allows a user to update only selected portions of an array within the FPGA. This activity is the functional equivalent of putting several smaller FPGAs within a single package. However, the associated configuration software still does not provide a user with information about the underlying configuration data, nor the effects of changing the data. Furthermore, the configuration software is incapable of mapping user-described parameter changes onto the configuration data.
As a second example, application notes have been published by vendors of micro-controllers and micro-controller peripherals for products that include sample source code listings. However, these source code listings are only capable of addressing configuration of hardwired options within a specific device, such as defining a port as either an input port or an outport port, or in order to set one of several pre-defined baud rates. Furthermore, such application notes are only applicable to fixed hardware and fixed functionality applications.